After doing some research and thinking about

• what exception classes we have and what they're used for,
• how other HTTP / HTTP-using frameworks define their exceptions,
• the questions mentioned earlier

I came to this proposal that shall close #80:

a HttpResponse body may or may not be consumable (think about a streaming transfer that is already finished)

Same for the request body. DavException handles those cases and doesn't set a request/response excerpt then. Also added the JSR 305 @WillNotClose to make clear that the DavException won't close the response (so it's the responsibility of the caller, who should always use use or try/finally).

it's not clear why the whole response is needed in the exception,

It's handy for constructing the response. This pattern is also used for instance in Ktor's ResponseException.

it could cause problems when we try to serialize the exception,

True → added test for JVM serialization, because Exception base class is Serializable.

it couples a HTTP-level data class with a specific HTTP implementation.

Only for construction. To make this clear, I changed the primary constructor so that it takes only simple values. HttpResponse parsing is moved to a secondary constructor.

Further notes / changes:

• Simplified request / response body logic and XML error extraction.
• Exceptions for specific HTTP error codes now validate the error code to avoid mistakes.
• Make InvalidPropertyException a subclass of DavException.
• Simplify DavResource.checkStatus().
• Made Error a data class so that it prints the error names in toString() and errors can be compared.